DBインスタンスは仮想機器とインストールされたMySQLを包括する概念で、 RDS for MySQLが提供するMySQLの単位です。 DBインスタンスのOSに直接アクセスすることはできず、DBインスタンス作成時に入力したポートを介してデータベースにのみアクセスできます。使用できるポート範囲には以下のような制約事項があります。
DBインスタンスは、顧客が付与する名前と自動的に付与される32バイトのIDで識別されます。 DBインスタンス名は下記のような制約事項があります。
DBインスタンスは作成時にユーザーアカウントとパスワードを設定する必要があり、下記のような制約があります。
NHN Cloudは、物理的なハードウェアの問題で生じる障害に備えるため、システム全体を複数のアベイラビリティゾーンに分けています。このアベイラビリティゾーンごとに、ストレージシステム、ネットワークスイッチ、ラック、電源装置がすべて別々に構成されています。1つのアベイラビリティゾーン内で起こる障害は他のアベイラビリティゾーンに影響を与えないため、サービス全体の可用性が高くなります。DBインスタンスを複数のアベイラビリティゾーンに分けて構築すれば、サービスの可用性をさらに高めることができます。複数のアベイラビリティゾーンに分散して作成されたDBインスタンス同士でネットワーク通信が可能で、この時発生するネットワーク使用費用は請求されません。
[注意] すでに作成したDBインスタンスのアベイラビリティゾーンは変更できません。
以下に明示されたバージョンを使用できます。
| バージョン | 備考 |
|---|---|
| 8.0 | |
| MySQL 8.0.35 | |
| MySQL 8.0.34 | |
| MySQL 8.0.33 | |
| MySQL 8.0.32 | |
| MySQL 8.0.28 | |
| MySQL 8.0.23 | |
| MySQL 8.0.18 | |
| 5.7 | |
| MySQL 5.7.37 | |
| MySQL 5.7.33 | 外部のバックアップでDBインスタンスを復元できません。 |
| MySQL 5.7.26 | |
| MySQL 5.7.19 | |
| MySQL 5.7.15 | |
| 5.6 | |
| MySQL 5.6.33 | 新規DBインスタンスを作成できません。既存DBインスタンスのリードレプリカ作成、復元のみサポートします。 |
DBエンジンの場合、作成後、Webコンソールの修正機能でバージョンアップが可能です。 DBエンジンの詳細はDBエンジンで確認できます。
DBインスタンスはタイプごとに異なるCPUコア数とメモリ容量を持っています。 DBインスタンス作成時、データベースのワークロードに応じて適切なDBインスタンスタイプを選択する必要があります。
| タイプ | 説明 |
|---|---|
| m2 | CPUとメモリをバランスよく設定したタイプです。 |
| c2 | CPUのパフォーマンスを高く設定したインスタンスタイプです。 |
| r2 | 他のリソースに比べてメモリの使用量が多い場合に使用できます。 |
| x1 | 高スペックのCPUとメモリをサポートするタイプです。高性能が必要なサービスやアプリケーションに使用します。 |
作成済みのDBインスタンスのタイプはWebコンソールから簡単に変更できます。
[注意] 作成済みのDBインスタンスのタイプを変更すると、DBインスタンスが終了するため、多少の中断時間が発生します。
DBインスタンスの状態は下記のような値で構成され、ユーザーの行為と現在の状態によって変更されます。
| 状態 | 説明 |
|---|---|
| BEFORE_CREATE | 作成前 |
| AVAILABLE | 使用可能 |
| STORAGE_FULL | 容量不足 |
| FAIL_TO_CREATE | 作成失敗 |
| FAIL_TO_CONNECT | 接続失敗 |
| REPLICATION_STOP | 複製中断 |
| FAILOVER | フェイルオーバー完了 |
| FAILOVER_SHUTDOWN | フェイルオーバー完了(停止), 2023年4月11日以前にフェイルオーバーしたDBインスタンス |
| SHUTDOWN | 停止した |
DBインスタンスで実行される作業は下記のような値で構成され、Webコンソールの操作または事前に指定された自動化バッチに基づいて作業が始まります。
| 作業 | 説明 |
|---|---|
| APPLYING_PARAMETER_GROUP | パラメータグループの適用中 |
| BACKING_UP | バックアップ中 |
| CANCELING | キャンセル中 |
| CREATING | 作成中 |
| CREATING_SCHEMA | DBスキーマの作成中 |
| CREATING_USER | ユーザーの作成中 |
| DELETING | 削除中 |
| DELETING_SCHEMA | DBスキーマの削除中 |
| DELETING_USER | ユーザーの削除中 |
| EXPORTING_BACKUP | バックアップのエクスポート中 |
| FAILING_OVER | フェイルオーバー中 |
| MIGRATING | マイグレーション中 |
| MODIFYING | 修正中 |
| NONE | なし |
| PREPARING | 準備中 |
| PROMOTING | 昇格中 |
| PROMOTING_FORCIBLY | 強制昇格中 |
| REBUILDING | 再構築中 |
| REPAIRING | 復旧中 |
| REPLICATING | 複製中 |
| RESTARTING | 再起動中 |
| RESTARTING_FORCIBLY | 強制再起動中 |
| RESTORING | 復元中 |
| STARTING | 起動中 |
| STOPPING | 停止中 |
| SYNCING_SCHEMA | DBスキーマの同期中 |
| SYNCING_USER | ユーザーの同期中 |
| UPDATING_USER | ユーザーの修正中 |
| WAIT_MANUAL_CONTROL | フェイルオーバー手動制御待機中 |
[注意] DBインスタンスは一度に1つの作業しか処理できません。 同時に作業をリクエストした場合、先にリクエストした作業のみ成功し、後にリクエストした作業はすべて失敗することになります。 リクエストに失敗した作業は、イベント画面で確認できます。
DBインスタンスはHDD、SSDの2種類のデータストレージタイプをサポートします。データストレージの種類によって性能と価格が異なるため、データベースのワークロードに応じて適切なタイプを選択する必要があります。データストレージは20GB～2TBで作成できます。
DBインスタンスのストレージの種類は変更できませんが、ストレージサイズはWebコンソールで簡単に拡張できます。ストレージサイズの拡張過程でDBインスタンスが終了し、サービス負荷に応じて多少のダウンタイムが発生します。リードレプリカが存在する場合、マスターのストレージサイズ拡張時にリードレプリカのストレージサイズも一緒に拡張されます。読み取りレプリカが複数台ある場合、ストレージサイズの拡張は順次行われます。ストレージサイズの拡張中にエラーが発生した場合、一部のリードレプリカのストレージサイズが拡張されない場合があり、拡張に失敗したリードレプリカの場合、その後個別に拡張できます。ストレージサイズは現在のサイズより小さく変更することはできません。
DBインスタンスのデータストレージの種類は変更できませんが、データストレージのサイズはWebコンソールで簡単に拡張できます。データストレージサイズの拡張過程でDBインスタンスが終了し、サービス負荷によって多少のダウンタイムが発生します。 リードレプリカが存在する場合、マスターのデータストレージサイズを拡張すると、リードレプリカのデータストレージサイズも一緒に拡張されます。リードレプリカが複数ある場合、データストレージサイズの拡張は順次行われます。データストレージサイズの拡張中にエラーが発生した場合、一部のリードレプリカのデータストレージサイズが拡張されない場合があり、拡張に失敗したリードレプリカの場合、その後個別に拡張可能です。データストレージのサイズは、現在のサイズより小さく変更することはできません。
[注意] 作成済みのDBインスタンスのサブネットは変更できません。
外部からDBインスタンスにアクセスするには、Floating IPをDBインスタンスに接続する必要があります。Internet Gatewayが接続されたサブネットを接続する場合のみFloating IPを作成できます。Floating IPは使用と同時に課金され、これとは別にFloating IPを介したインターネット方向のトラフィックが発生する場合は別途課金されます。
DBセキュリティグループは、外部からの侵入に備えて接続を制限するために使用します。送受信トラフィックに対して特定のポート範囲あるいはデータベースポートに対してアクセスを許可できます。DBインスタンスに複数のDBセキュリティグループを適用できます。DBセキュリティグループの詳しい説明はDBセキュリティグループを参照してください。
DBインスタンスのデータベースを定期的にバックアップするように設定したり、Webコンソールから好きなタイミングでバックアップを作成できます。バックアップが実行されている間、パフォーマンスの低下が発生する場合があります。サービスに影響を与えないように、サービスの負荷が少ない時間にバックアップすることを推奨します。バックアップによる性能低下を望まない場合は、高可用性構成を使用するか、読み取りレプリカでバックアップを実行できます。バックアップファイルは内部バックアップストレージに保存され、バックアップ容量に応じて課金されます。必要に応じて、NHN Cloudのユーザーオブジェクトストレージにエクスポートできます。予期せぬ障害に備えるため、定期的にバックアップを行うように設定することを推奨します。バックアップの詳細については、バックアップと復元を参照してください。
バックアップを利用して新しいDBインスタンスを作成できます。バックアップを実行したDBインスタンスとバイナリログ(binary log)が存在する場合、特定の時点あるいは希望のバイナリログ(binary log) positionに復元が可能です。RDS for MySQLではなく、外部MySQLのバックアップでも復元が可能です。復元時には常に新しいDBインスタンスが作成され、既存のDBインスタンスのデータベースを消去して復元することはできません。復元に関する詳しい説明はバックアップと復元を参照してください。
DBインスタンス作成時、基本通知を設定できます。基本通知を設定すると、{{DBインスタンス名}-defaultという名前で新しい通知グループが作成され、下記の通知項目が自動で設定されます。基本通知として作成された通知グループは自由に修正、削除できます。通知グループについての詳しい説明は通知グループを参照してください。
| 項目 | 比較方法 | しきい値 | 持続時間 |
|---|---|---|---|
| CPU使用率 | >= | 80% | 5分 |
| Storageの空き容量 | <= | 5,120MB | 5分 |
| Database Connection Status | <= | 0 | 0分 |
| Storage使用量 | >= | 95% | 5分 |
| データストレージ障害 | <= | 0 | 0分 |
| Connection Ratio | >= | 85% | 5分 |
| メモリ使用量 | >= | 90% | 5分 |
| Slow Query | >= | 60 counts/min | 5分 |
DBインスタンスを一定時間使用しないが、削除を望まない場合、停止することができます。停止されたDBインスタンスの仮想機器は終了され、再起動するまでは使用できません。停止した状態のDBインスタンスは、停止した瞬間から90日間割引された料金が課金され、90日が過ぎた時点からは通常料金が課金されます。不要な料金が請求されないように、使用しないDBインスタンスは必ず削除してください。
[参考] 高可用性DBインスタンス、読み取りレプリカを持っているマスター、読み取りレプリカは停止できません。 DBインスタンスがFloating IPを使用している場合、停止に関係なくFloating IPの料金が課金されます。
読み取り性能を高めるために、読み取り専用に使用できるリードレプリカを作成できます。リードレプリカは1つのマスターに対して最大5台まで作成できます。リードレプリカのリードレプリカは作成できません。リードレプリカは、マスターと同じ仕様またはより高い仕様で作成することを推奨します。低い仕様で作成すると、複製遅延が発生する場合があります。
[注意] リードレプリカ作成時、マスターのI/O性能が通常より低くなることがあります。 マスターのデータベースサイズに比例して、リードレプリカの作成時間が長くなることがあります。
[参考] リードレプリカの作成過程で必要なバイナリログ(binary log)サイズ分、バックアップストレージ課金が発生する可能性があります。
マスターとの複製関係を切って、リードレプリカをマスターに変更することを昇格と呼びます。昇格したマスターは、独立したDBインスタンスとして動作します。昇格しようとするリードレプリカとマスターの間に複製遅延がある場合、その遅延がなくなるまで昇格されません。
マスターや原本リージョンの状態に関係なく、リードレプリカの現時点のデータで強制昇格します。
リードレプリカは、さまざまな理由で複製が中断されることがあります。リードレプリカの状態が複製中断の場合、すぐに原因を確認して正常化する必要があります。複製中断状態が長時間続く場合、複製ディレイが長くなります。正常化に必要なバイナリログ(binary log)がない場合、リードレプリカを再構築する必要があります。複製が中断した原因はリードレプリカでSHOW SLAVE STATUSコマンドを使用して確認できます。Last_Errnoの値が1062の場、以下のProcedureをエラーが消えるまで呼び出せます。
mysql> CALL mysql.tcrds_repl_skip_repl_error();
リードレプリカの複製中断を解決できない状況の場合、再構築により正常化できます。リードレプリカの再構築時、リードレプリカのデータベースをすべて削除し、マスターのデータベースを基に再構築します。この過程で再構築に必要なバックアップファイルがマスターに存在しない場合、マスターでバックアップが行われ、バックアップによる性能低下が発生する可能性があります。
DBインスタンスのMySQLが正常に動作しない場合、強制的に再起動できます。強制再起動の場合、MySQLにSIGTERMコマンドを実行して正常終了するのを10分間待ちます。10分以内にMySQLが正常終了したら仮想マシンを再起動します。 10分以内に正常終了しない場合は仮想マシンを強制的に再起動します。仮想マシンが強制的に再起動されると、作業中の一部のトランザクションが失われる可能性があり、データボリュームが破損して復旧ができなくなる可能性があります。強制再起動後、DBインスタンスの状態が使用可能な状態に戻らない場合があります。このような状況が発生した場合は、カスタマーセンターにお問い合わせください。
[注意] データが失われたり、データボリュームが破損する可能性があるため、この機能は緊急かつ不可避な状況以外では使用を控えてください。
[参考] 高可用性DBインスタンスの場合は強制再起動できません。
急激な負荷でバイナリログ(binary log)が過剰に生成され、データストレージの容量が不足する場合、Webコンソールの容量確保機能を利用してバイナリログを削除できます。Webコンソールで容量確保を選択すると、DBインスタンスのバイナリログを選択できるポップアップ画面が表示されます。バイナリログを選択した後、OKを押して選択した項目より前に生成された全てのバイナリログを削除します。容量確保機能は一時的に容量を確保する機能です。継続して容量が不足する場合は、サービス負荷に合わせてバイナリログの保存期間を設定するか、データストレージのサイズを拡張する必要があります。
[参考] MySQL 5.7バージョン以下では
expire_logs_days、MySQL 5.8バージョン以上ではbinlog_expire_logs_secondsパラメータでバイナリログ(binary log)の保存期間を設定できます。[注意] 削除されたバイナリログ(binary log)によっては、特定の時点への復元ができない場合があります。
DBインスタンスに接続されたパラメータグループのパラメータが修正された場合、その修正を反映する必要があります。変更されたパラメータを適用するために再起動が必要な場合、DBインスタンスが再起動されます。パラメータグループの詳細については、パラメータグループを参照してください。
RDS for MySQLではDBスキーマとユーザーを簡単に管理できるようにWebコンソールで管理機能を提供していますが、ユーザーが直接制御できるように設定する機能も提供しています。WebコンソールのDBインスタンス修正画面でDBスキーマ＆ユーザー直接制御の項目で設定できます。 * 直接制御を使用すると、現在作成されているすべてのユーザーに下記の権限を付与します。
GRANT CREATE,DROP,LOCK TABLES,REFERENCES,EVENT,ALTER,INDEX,INSERT,SELECT,UPDATE,DELETE,CREATE VIEW,SHOW VIEW,CREATE ROUTINE,ALTER ROUTINE,EXECUTE,CREATE USER,PROCESS,RELOAD,REPLICATION SLAVE,REPLICATION CLIENT,SHOW DATABASES, CREATE TEMPORARY TABLES,TRIGGER ON *.* TO '{user_id}'@'{host}' WITH GRANT OPTION;
直接コントロールを使用した後、再度使用しないに変更した時の注意点 * 既に付与した権限を回収しません。 この時、コマンドを使用してDBスキーマやユーザーを追加すると、Webコンソールのデータと整合性が合わなくなる場合があります。 * ユーザーに付与された権限と関係なく、データベースに存在するすべてのユーザーはCUSTOM権限で表現されます。
高可用性DBインスタンスは可用性とデータ耐久性を増加させ、障害許容が可能なデータベースを提供します。高可用性DBインスタンスはマスター、予備マスターで構成され、異なるアベイラビリティゾーンに作成されます。予備マスターは障害に備えたDBインスタンスで、通常は使用できません。高可用性DBインスタンスの場合、予備マスターでバックアップが行われます。
[参考] 高可用性DBインスタンスの場合、MySQLクエリ文を使用して他のDBインスタンスまたは外部MySQLのMasterから強制的に複製するように設定すると、高可用性および一部の機能が正常に動作しません。
予備マスターには障害を検出するためのプロセスが存在し、定期的にマスターの状態を検出します。このような検出周期をPing間隔と呼び、4回連続状態チェックに失敗した場合、フェイルオーバーを実行します。Ping間隔が短いほど障害に敏感に反応し、Ping間隔が長いほど障害に鈍感に反応します。サービス負荷に合わせて適切なPing間隔を設定することが重要です。
[参考] マスターのデータストレージ使用量がいっぱいになると、高可用性監視プロセスが障害として検出し、フェイルオーバーを実行するので注意してください。
予備マスターでマスターの状態チェックに4回連続失敗した場合、マスターがサービスを提供できないと判断し、自動的にフェイルオーバーを実行します。スプリットブレイン防止のため、障害が発生したマスターに割り当てられたすべてのユーザーセキュリティグループの接続を解除して外部からの接続を遮断し、予備マスターがマスターの役割を代行します。接続のための内部ドメインのA recordは障害が発生したマスターから予備マスターに変更されるので、アプリケーションの変更は必要ありません。フェイルオーバーが完了すると、障害が発生したマスターの種類はフェイルオーバーが発生したマスターに、予備マスターの種類はマスターに変更されます。フェイルオーバーが発生したマスターを復旧または再構築するまでフェイルオーバーは実行されません。昇格されたマスターは、フェイルオーバーが発生したマスターのすべての自動バックアップを継承します。フェイルオーバーの過程でマスターが変更されると、バイナリログがすべて削除されるため、既存のバックアップを利用した時点復元はサポートされません。昇格されたマスターで新規にバックアップが行われた時点から時点復元を行うことができます。
[参考] 高可用性機能はドメインに基づいているため、接続をしようとするクライアントがDNSサーバーに接続できないネットワーク環境の場合、ドメインを介してDBインスタンスに接続することができず、フェイルオーバー発生時、正常な接続ができません。 内部ドメインのA recordの変更が反映されるのに約3秒程度かかります。所要時間は、接続を試みるクライアント環境のDNS Cacheポリシーによって異なる場合があります。
[注意] マスターと予備マスター間のバイナリログ(binary log)のposition numberの値が100,000,000,000以上差がある場合、フェイルオーバーが行われません。
障害が発生してフェイルオーバーが発生したマスターをフェイルオーバーが発生したマスターといいます。フェイルオーバーが発生したマスターの自動バックアップは行われず、フェイルオーバーが発生したマスターの復旧、再構築、分離、削除を除く他のすべての機能は実行できません。
フェイルオーバーの過程でデータの整合性が崩れず、障害が発生した時点から復旧を試みる時点までバイナリログ(binary log)が失われなければフェイルオーバーが発生したマスターと昇格したマスターを再び高可用性構成で復旧できます。フェイルオーバーが発生したマスターのデータベースをそのまま昇格されたマスターと複製関係を再設定するため、データの整合性が崩れたり復旧に必要なバイナリログ(binary log)が失われた場合、復旧は失敗します。フェイルオーバーが発生したマスターの復旧に失敗した場合、再構築を通じて再び高可用性機能を有効にできます。
[参考] 2023年4月11日以前にフェイルオーバーが発生したDBインスタンスの場合、復旧をサポートしません。
フェイルオーバーが発生したマスターの復旧に失敗した場合、再構築を利用して再び高可用性機能を有効にできます。再構築は復旧とは異なり、フェイルオーバーが発生したマスターのデータベースを全て削除し、昇格されたマスターのデータベースを基に再構築します。この過程で再構築に必要なバックアップファイルが昇格されたマスターに存在しない場合、バックアップが行われ、バックアップによる性能低下が発生する可能性があります。
フェイルオーバーが発生したマスターの復旧に失敗してデータ補正が必要な場合、そのマスターを分離して高可用性機能を無効にできます。分離されたマスターと昇格されたマスター間の複製関係が切断され、それぞれ一般DBインスタンスとして動作します。分離後は既存の構成に戻せません。
高可用性DBインスタンスの場合、再起動を伴う作業を実行すると、フェイルオーバーを利用した再起動を行うかどうかを選択でき、その作業は次のとおりです。
フェイルオーバーを利用した再起動を行うと、予備マスターを先に再起動します。その後、フェイルオーバーにより予備マスターをマスターに昇格させ、既存のマスターは予備マスターの役割をすることになります。昇格時に接続のための内部ドメインのA recordはマスターから予備マスターに変更されるので、アプリケーションの変更は必要ありません。昇格されたマスターは、以前のマスターのすべての自動バックアップを継承します。フェイルオーバーの過程でマスターが変更され、バイナリログ(binary log)がすべて削除されるため、既存のバックアップを利用した時点復元はサポートしません。昇格されたマスターで新規にバックアップが行われた時点から時点復元を行うことができます。
[参考] フェイルオーバーを利用して再起動を行わなければ、マスターと予備マスターが順次再起動します。
[注意] 予備マスターの複製ディレイ
Seconds_Behind_Masterの値が1以上の場合、手動フェイルオーバーが失敗します。複製ディレイにより再起動が失敗した場合はイベント画面で確認できます。
一時的な作業による接続中断や大量の負荷が予想される状況で、一時的に高可用性機能を停止できます。高可用性機能が一時停止されると、障害を検出しないため、フェイルオーバーを実行しません。高可用性機能が一時停止した状態で再起動が必要な作業を実行しても一時停止された高可用性機能が再開されません。高可用性機能が一時停止するとデータ複製は正常に行われず、障害が検出されないため、長時間一時停止状態に維持することは推奨しません。
ネットワークの切断、誤ったFEDERATEDエンジンの使用、他のマスターからの複製設定など、さまざまな原因で予備マスター複製が中断されることがあります。複製中断状態の予備マスターは自動フェイルオーバーが実行されません。予備マスターの複製中断を解決するには予備マスターを再構築する必要があります。予備マスターの再構築時には予備マスターのデータベースをすべて削除し、マスターのデータベースを基に再構築します。この過程で再構築に必要なバックアップファイルがマスターデータベースに存在しない場合、マスターでバックアップが行われ、バックアップによる性能低下が発生する可能性があります。
予備マスターも読み取りレプリカと同様に、マスターとの複製関係を切ってマスターに昇格させることができます。高可用性を解除してリードレプリカに変更した後、リードレプリカ昇格と同じ作業を行います。昇格しようとする予備マスターとマスターの間に複製遅延がある場合、その遅延がなくなるまで昇格されません。
マスターの状態に関係なく、予備マスターの現在時点のデータで強制昇格します。
RDS for MySQLはユーザーに利便性を提供するため、ユーザーアカウントで制限されるいくつかの機能を実行するプロシージャを独自に提供しています。
mysql> CALL mysql.tcrds_active_process();
mysql> CALL mysql.tcrds_process_kill(processlist_id );
mysql> CALL mysql.tcrds_current_lock();
mysql> CALL mysql. tcrds_repl_changemaster (master_instance_ip, master_instance_port, user_id_for_replication, password_for_replication_user, MASTER_LOG_FILE, MASTER_LOG_POS);
ex) call mysql.tcrds_repl_changemaster('10.162.1.1',10000,'db_repl','password','mysql-bin.000001',4);
[注意]複製用アカウントが複製対象(Master) MySQLに作成されている必要があります。
mysql> CALL mysql.tcrds_repl_init();
mysql> CALL mysql.tcrds_repl_slave_stop();
mysql> CALL mysql.tcrds_repl_slave_start();
MySQL error code 1062: 'Duplicate entry ? for key ?'mysql> CALL mysql.tcrds_repl_skip_repl_error();
例) MySQL error code 1236 (ER_MASTER_FATAL_ERROR_READING_BINLOG): Got fatal error from master when reading data from binary log
mysql> CALL mysql.tcrds_repl_next_changemaster();
SET GLOBAL innodb_monitor_reset = '{counter-name|module_name|pattern|all}';クエリを実行します。mysql> CALL mysql.tcrds_innodb_monitor_reset('{counter-name|module_name|pattern|all}');
ex) CALL mysql.tcrds_innodb_monitor_reset('dml_reads');
CALL mysql.tcrds_innodb_monitor_reset('module_dml');
SET GLOBAL innodb_monitor_reset_all = '{counter-name|module_name|pattern|all}';クエリを実行します。mysql> CALL mysql.tcrds_innodb_monitor_reset_all('{counter-name|module_name|pattern|all}');
mysqldump -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
mysqldump -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --routines --events --triggers --databases {database_name1, database_name2, ...} | mysql -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port}
mysqldump -h{external_db_host} -u{external_db_id} -p{external_db_password} --port={external_db_port} --single-transaction --set-gtid-purged=off --routines --events --triggers --databases {database_name1, database_name2, ...} | mysql -h{rds_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port}
ERROR 1227エラーが発生した場合ERROR 1227エラーはmysqldumpファイルの保存されたオブジェクト(トリガー、ビュー、関数またはイベント)にDEFINERが定義されている時に発生します。これを解決するためには、mysqldumpファイルでDEFINER部分を削除してください。ERROR 1418エラーが発生する場合ERROR 1418エラーはmysqldumpファイルの関数宣言にNO SQL、READS SQL DATA, DETERMINISTICがなく、バイナリログが有効な状態の時に発生します。log_bin_trust_function_creatorsパラメータの値を1に変更する必要があります。mysqldump -h{rds_master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --master-data=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
mysqldump -h{rds_read_only_slave_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --dump-slave=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
...
[mysqld]
...
server-id={server_id}
replicate-ignore-db=rds_maintenance
...
mysql -h{external_db_host} -u{exteranl_db_id} -p{external_db_password} --port={exteranl_db_port} < {local_path_and_file_name}
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO master_host = '{rds_master_instance_floating_ip}', master_user='{user_id_for_replication}', master_password='{password_forreplication_user}', master_port ={rds_master_instance_port}, master_log_file ='{MASTER_LOG_FILE}', master_log_pos = {MASTER_LOG_POS};
START SLAVE;
mysqldump -h{master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --master-data=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
mysqldump -h{slave_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} --single-transaction --dump-slave=2 --routines --events --triggers --databases {database_name1, database_name2, ...} > {local_path_and_file_name}
...
[mysqld]
...
server-id={server_id}
replicate-ignore-db=rds_maintenance
...
mysql -h{rds_master_insance_floating_ip} -u{db_id} -p{db_password} --port={db_port} < {local_path_and_file_name}
mysql> CREATE USER 'user_id_for_replication'@'{external_db_host}' IDENTIFIED BY '<password_forreplication_user>';
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'user_id_for_replication'@'{external_db_host}';
mysql> call mysql.tcrds_repl_changemaster ('rds_master_instance_floating_ip',rds_master_instance_port,'user_id_for_replication','password_forreplication_user','MASTER_LOG_FILE',MASTER_LOG_POS );
mysql> call mysql.tcrds_repl_slave_start;
mysql> call mysql.tcrds_repl_init();